Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

as much as it hurts, async is holding us back #9

Closed
wants to merge 2 commits into from

Conversation

fabi321
Copy link
Contributor

@fabi321 fabi321 commented Jun 17, 2023

About my testing: for some reason, I can't push loopback further than ~40Gbit/s on my machine, no matter the connections.

On the other hand, if I only flood with a single connection, I get ~10Gbit/s with sturmflut with the async version, with breakwater running at 102% cpu. With the sync version, I get ~14Gbit/s, still at 102% cpu usage.

I'm not saying that I like the sync version more than the async version, but it is definitely noticeably faster. If I hammer them with 10 connections, both versions perform similar in terms of bandwidth.

Tests are not changed to sync yet

About my testing: for some reason, I can't push loopback further than ~40Gbit/s on my machine, no matter the connections.

On the other hand, if I only flood with a single connection, I get ~10Gbit/s with sturmflut with the async version, with breakwater running at 102% cpu. With the sync version, I get ~14Gbit/s, still at 102% cpu usage.

I'm not saying that I like the sync version more than the async version, but it is definitely noticeably faster. If I hammer them with 10 connections, both versions perform similar in terms of bandwidth.
@fabi321 fabi321 marked this pull request as draft June 17, 2023 14:19
@fabi321
Copy link
Contributor Author

fabi321 commented Jun 17, 2023

something else to note: if I use pixelbomber, that roughly halves the amount of bytes per pixel, with the async version, I get only ~6.5Gbit/s, but with the sync version, I get 14Gbit/s, just like with sturmflut.

@sbernauer
Copy link
Owner

Thx for the measurements, would you suggest switching back to non-async code?

@fabi321
Copy link
Contributor Author

fabi321 commented Jun 18, 2023

I'm still searching for the caveat in them. It's probably just that we let the kernel manage threads and interrupts, and if we use async, we do the same again, just in tokio.

Feel free to verify these findings.

@fabi321
Copy link
Contributor Author

fabi321 commented Jun 18, 2023

After testing different features, I noticed, that my async performance isn't that bad. Was probably just me confusing earlier benchmarks

@fabi321 fabi321 closed this Jun 18, 2023
@sbernauer
Copy link
Owner

Puh, good news! Thanks for the update!

@fabi321 fabi321 deleted the sync branch June 20, 2023 18:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants